home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group93a.txt
/
000034_icon-group-sender _Tue Jan 19 13:52:49 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1993-04-21
|
2KB
Received: by cheltenham.cs.arizona.edu; Tue, 19 Jan 1993 06:26:55 MST
Date: Tue, 19 Jan 1993 13:52:49 +0100
From: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber)
Message-Id: <9301191252.AA09689@soir.informatik.uni-tuebingen.de>
To: sbw@turing.cse.nau.edu
Cc: icon-group@cs.arizona.edu
In-Reply-To: Steve Wampler's message of Mon, 18 Jan 1993 08:43:05 MST <9301181543.AA01233@turing.cse.nau.edu>
Subject: Pattern matching in Icon?
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
Finally, it seems I've been able to get through with the essence of my
proposal. Sorry for all the confusion; it's probably that I'm working
on a compiler project right now that is written in SML. Pattern
matching is just humungously convenient for syntax transformation.
I'm sorry if the impression was that I wanted pattern matching in the
core language of Icon - as I said, a variant translator would
probably be closest to what I want. However, since it's stated so
often that Icon is aimed at compiler writing, I thought that others
might have already done some thinking on the matter: I guess it's the
generators that make Icon convenient for compiler writing, but
actually, that's EXACTLY what the functional-language people say of
pattern matching in their languages. Now, Steve Wampler writes:
>You find adding two assignment operators to your original syntax
>'extremely' awkward? Why? More awkward, yes. But I don't see
>that as 'extremely'! Or is that you're writing your own pattern
>matching function(s) that you see as awkward? Again, you write them
>once, hide them away in a library, and presto, no difference there
>with having them built into the language -- except that you can
>*change* them!
The code itself is not that complicated. However, the advantage of
pattern matching is that you usually specifiy lots of
differently-structured (and recursive invokations) patterns in a
single case. Since for EVERY record constructor and for EVERY
structural variant of patterns that you use, you'd need to write a
different matching function, indeed things would typically get very
bothersome: You cannot just intuitively add patterns to a case
without thinking about how the matching procedure for the specific
structural variant is called and how it's invoked. So I contend: Yes,
VERY awkward.
Cheers :-> Chipsy